1. Field of the Invention
The present invention generally relates to computer software programs and databases to be used in Financial Service Organizations. More particularly, the present invention relates to the dynamic selection of a database identifier, associated with a database, based on application program requirements in a Financial Service Organization (FSO) business transaction processing system.
2. Description of the Related Art
FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing.
Databases may be used in FSO business transaction processing systems to store, manage and retrieve data for a variety of applications. In many instances, the databases may be extremely large. The contents of the database may often occupy memory space measured in hundred's of gigabytes. When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO business transaction processing systems often utilize commercially available database products. One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM).
Some nomenclature is introduced here to aid in the understanding of terminology used. A database packageset contains information needed by the FSO database software to locate and access data in the most efficient way for a particular application program in the FSO business transaction processing system. Database packageset switching occurs when the database packageset values associated with one application program are changed to the database packageset values associated with another application program in the same business transaction processing system. Dynamic database packageset switching occurs when the database packageset values associated with one application program are changed in real-time to the database packageset values associated with another application program in the same business transaction processing system. FSO database environmental variables and database registry values may contain information to control a specific database environment within the FSO business transaction processing system. The user may change environmental variables and registry values to change the FSO database environment.
An example of an FSO that may use such a business transaction processing system is a credit card institution. A credit card institution may issue credit cards to customers of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. The credit card institution may also have a client department store. The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, charging a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution.
The FSO business transaction processing system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of the data items or elements in the database. For example, the FSO business transaction processing system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. Groups of data such as master files and transactions may be comprised of data elements defined in the data dictionary. Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer.
The FSO business transaction processing system may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in the FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction. Another example of a processing parameter may be a database identifier, which may point to the location of the data in an FSO database.
The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction.
A combination of data elements used to determine the value of a processing parameter may be referred to as a key definition for the processing parameter. The combination of data element values constructed from the key definition may be referred to as a key value. For example, a software program for processing credit card transactions for a credit card institution may use the credit card issuer and card type to determine the database identifier.
Key definitions and key value construction are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying the data dictionary and database structure used by the software programs. If more than one FSO use the software programs, customization of key definitions and key value construction for one of the FSOs requires creating and maintaining a customized copy of the source code for the programs.
In some FSO systems, processing parameters, such as the database identifier, and the key values used to identify them may be hardcoded in the source code for the FSO system software programs. Modifying the processing parameters and key values for these systems may involve modifying the source code for all software programs that use the processing parameter, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and key values may be stored in the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Thus, the processing parameters and key values in the database may be considered hardcoded as well, as they cannot be modified without also modifying the source code and rebuilding the programs as described above.
During the initial design and development phase of a large scale database application, such as the DB2, it may be necessary or desirable to have different database environments for Development, Quality, Testing, Production, etc. In addition, the Development environment may also be different, based on the operating system of the computer. It may be necessary or desirable to have one or more databases within one environment. For example, it may be desirable to have a separate database for each development engineer within one DB2 Development environment.
Database limitations may prohibit the use of multiple environments within the same database sub-system. The number of multiple databases within one environment within the same database sub-system may also be limited. One embodiment of a database, which may have some of these limitations is the DB2 database from International Business Machines (IBM). These limitations may often substantially reduce the flexibility of the FSO transaction processing application software program to adapt to changing business requirements. For example, an FSO business transaction processing system may need to expand and respond quickly to integrate a newly acquired FSO or process transactions from a new FSO location. A conventional method to implement these changes often involves changing the source code of the application program. This method is programming intensive, time consuming and costly.
The conventional method for the FSO transaction processing application software program developer to work around database environment restriction may be to manually modify the application program source code, in an off-line mode, to change the environment name in the database registry values. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Manual switching between the one or more database environments may often involve a shutdown and startup phase for the database sub-system. This is especially undesirable in installations, which attempt to operate continuously.
The conventional method for the FSO transaction processing application software program developer to avoid the difficulty of adding a new database name may be to add new data to an existing database name. As an alternate, the application software program developer could manually modify the application program source code, in an off-line mode, to change the database name in the DB2 registry values to the ‘new’ database name. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Both of these methods have drawbacks.
The method of adding new data to an existing DB2 database increases the size, often reducing the system performance and increasing maintenance complexity. The method of changing a database name by using applicable commands in the application programming language i.e. by modifying the source code, significantly increases the development time and the costs. For example, adding a new company database in an FSO may affect the source code in thousands of application programs.